Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/1wg-charters-by-acronym.txt

Text File | 1993-04-14 | 135KB | 3,441 lines

Internet Message Extensions (822ext)

Charter

Chair(s):
     Gregory Vaudreuil  <[e-mail]>

Applications Area Director(s)
     Brewster Kahle  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ietf.cnri.reston.va.us:~/ietf-mail-archive/822ext/*

Description of Working Group:

This Working Group was chartered to extend the RFC 822 Message format to
facilitate multi-media mail and alternate character sets.  RFCs 1341
and RFC 1342 document the Multi-Media Extensions for Internet Mail.

The Working Group will work to progress MIME to Draft Standard status
and provide a forum for the review of standards track content-type
specifications and the review of character set extensions to MIME.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Aug 92 Dec 92  <draft-ietf-822ext-iso2022jp-02.txt>
                Japanese Character Encoding for Internet Messages

 Feb 93 Apr 93  <draft-ietf-822ext-mime2-02.txt, .ps>
                Mechanisms for Specifying and Describing the Format of Internet
                Message Bodies

 Mar 93 New     <draft-ietf-822ext-mime-part2-00.txt>
                MIME (Multipurpose Internet Mail Extensions) Part Two:  Message
                Header Extensions for Non-ASCII Text

 Apr 93 Apr 93  <draft-ietf-822ext-md5-01.txt>
                The Content-MD5 Header

 Apr 93 New     <draft-ietf-822ext-content-type-00.txt, .ps>
                The text/enriched MIME Content-type

Internet Accounting (acct)

Charter

Chair(s):
     Cyndi Mills  <[e-mail]>
     Gregory Ruth  <[e-mail]>

Network Management Area Director(s)
     Marshall Rose  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Internet Accounting Working Group has the goal of producing
standards for the generation of accounting data within the Internet
that can be used to support a wide range of management and cost
allocation policies.  The introduction of a common set of tools and
interpretations should ease the implementation of organizational
policies for Internet components and make them more equitable in a
multi-vendor environment.

In the following accounting model, this Working Group is primarily
concerned with defining standards for the Meter function and
recommending protocols for the Collector function.  Individual
accounting applications (billing applications) and organizational
policies will not be addressed, although examples should be provided.

Meter $<$--$>$ Collector $<$--$>$ Application $<$--$>$ Policy

First, examine a wide range of existing and hypothetical policies to
understand what set of information is required to satisfy usage
reporting requirements.  Next, evaluate existing mechanisms to generate
this information and define the specifications of each accounting
parameter to be generated.  Determine the requirements for local storage
and how parameters may be aggregated.  Recommend a data collection
protocol and internal formats for processing by accounting applications.

This will result in an Internet-Draft suitable for experimental
verification and implementation.

In parallel with the definition of the draft standard, develop a suite
of test scenarios to verify the model.  Identify candidates for
prototyping and implementation.

\newpage

Internet Drafts:

  No Current Internet drafts.

IP over AppleTalk (appleip)

Charter

Chair(s):
     John Veizades  <[e-mail]>

Internet Area Director(s)
     Stev Knowles  <[e-mail]>
     David Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Macintosh Working Group is chartered to facilitate the connection
of Apple Macintoshes to IP internets and to address the issues of
distributing AppleTalk services in an IP internet.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 91 Nov 92  <draft-ietf-appleip-MacIP-02.txt>
                A Method for the Transmission of Internet Packets Over
                AppleTalk Networks [MacIP]

 Dec 92 New     <draft-ietf-appleip-mib2-00.txt>
                AppleTalk Management Information Base II

IP over Asynchronous Transfer Mode (atm)

Charter

Chair(s):
     Robert Hinden  <[e-mail]>

Internet Area Director(s)
     Stev Knowles  <[e-mail]>
     David Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           Send message to [e-mail]

Description of Working Group:

The IP over ATM Working Group will focus on the issues involved in
running internetworking protocols over Asynchronous Transfer Mode
(ATM) networks.  The final goal for the Working Group is to produce
standards for the TCP/IP protocol suite and recommendations which
could be used by other internetworking protocol standards (e.g., ISO
CLNP and IEEE 802.2 Bridging).

The Working Group will initially develop experimental protocols for
encapsulation, multicasting, addressing, address resolution, call set
up, and network management to allow the operation of internetwork
protocols over an ATM network.  The Working Group may later submit
these protocols for standardization.

The Working Group will not develop physical layer standards for ATM.
These are well covered in other standard groups and do not need to be
addressed in this Group.

The Working Group will develop models of ATM internetworking
architectures.  This will be used to guide the development of specific IP
over ATM protocols.

The Working Group will also develop and maintain a list of technical
unknowns that relate to internetworking over ATM.  These will be used
to direct future work of the Working Group or be submitted to other
standard or research groups as appropriate.

The Working Group will coordinate its work with other relevant
standards bodies (e.g., ANSI T1S1.5) to insure that it does not
duplicate their work and that its work meshes well with other
activities in this area.  The Working Group will select among ATM
protocol options (e.g., selection of an adaptation layer protocol) and
make recommendations to the ATM standards bodies regarding the
requirements for internetworking over ATM where the current ATM
standards do not meet the needs of internetworking.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jun 92 Mar 93  <draft-ietf-atm-multipro-06.txt>
                Multiprotocol Interconnect over ATM Adaptation Layer 5

 Mar 93 New     <draft-ietf-atm-address-resolve-00.txt>
                Partial Address Resolution in ATM Networks

 Mar 93 New     <draft-ietf-atm-address-translation-00.txt>
                IP over ATM : architecture, address translation, and call
                control

 Mar 93 New     <draft-ietf-atm-nbma-00.txt>
                NBMA Address Resolution Protocol (NBMA ARP)

Audio/Video Transport (avt)

Charter

Chair(s):
     Stephen Casner  <[e-mail]>

Transport Area Director(s)
     Allison Mankin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           nic.es.net:~/ietf/rem-conf/av-transport-archive

Description of Working Group:

     The Audio/Video Transport Working Group was formed to specify experimental
     protocols for real-time transmission of audio and video over UDP
     and IP multicast.  The focus of this Group is near-term and its
     purpose is to integrate and coordinate the current AV transport
     efforts of existing research activities.  No standards-track
     protocols are expected to be produced because UDP transmission of
     audio and video is only sufficient for small-scale experiments
     over fast portions of the Internet.  However, the transport
     protocols produced by this Working Group should be useful on a larger scale
     in the future in conjunction with additional protocols to access
     network-level resource management mechanisms.  Those mechanisms,
     research efforts now, will provide low-delay service and guard
     against unfair consumption of bandwidth by audio/video traffic.

     Similarly, initial experiments can work without any connection
     establishment procedure so long as a priori agreements on port
     numbers and coding types have been made.  To go beyond that, we
     will need to address simple control protocols as well.  Since IP
     multicast traffic may be received by anyone, the control
     protocols must handle authentication and key exchange so that the
     audio/video data can be encrypted.  More sophisticated connection
     management is also the subject of current research.  It is
     expected that standards-track protocols integrating transport,
     resource management, and connection management will be the result
     of later working group efforts.

     The AVT Working Group may design independent protocols specific to each
     medium, or a common, lightweight, real-time transport protocol
     may be extracted.  Sequencing of packets and synchronization
     among streams are important functions, so one issue is the form
     of timestamps and/or sequence numbers to be used.  The Working Group will
     not focus on compression or coding algorithms which are domain of
     higher layers.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 92 New     <draft-ietf-avt-issues-00.txt, .ps>
                Issues in Designing a Transport Protocol for Audio and Video
                Conferences and other Multiparticipant Real-Time Applications

 Dec 92 New     <draft-ietf-avt-rtp-00.txt>
                A Transport Protocol for Real-Time Applications

 Dec 92 New     <draft-ietf-avt-encodings-00.txt>
                Media Encodings

 Dec 92 New     <draft-ietf-avt-profile-00.txt>
                Sample Profile for the Use of RTP for Audio and Video
                Conferences with Minimal Control

 Mar 93 New     <draft-ietf-avt-video-packet-00.txt>
                Packetization of H.261 video streams

Border Gateway Protocol (bgp)

Charter

Chair(s):
     Yakov Rekhter  <[e-mail]>

Routing Area Director(s)
     Robert Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

Develop the BGP protocol and BGP technical usage within the Internet,
continuing the current work of the Interconnectivity Working Group in
this regard.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Aug 91 Oct 92  <draft-ietf-bgp-multicast-02.txt>
                IP Multicast Communications Using BGP

 May 92 Dec 92  <draft-ietf-bgp-bgp4-04.txt>
                A Border Gateway Protocol 4 (BGP-4)

 Sep 92 Dec 92  <draft-ietf-bgp-mibv4-01.txt>
                Definitions of Managed Objects for the Border Gateway Protocol
                (Version 4)

 Sep 92 Mar 93  <draft-ietf-bgp-bgp4ospf-interact-01.txt>
                BGP4/IDRP for IP---OSPF Interaction

 Sep 92 Oct 92  <draft-ietf-bgp-application-01.txt>
                Application of the Border Gateway Protocol in the Internet

BGP Deployment and Application (bgpdepl)

Charter

Chair(s):
     Jessica Yu  <[e-mail]>

Operational Requirements Area Director(s)
     Scott Bradner  <[e-mail]>
     Bernhard Stockman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           merit.edu:~/pub/bgpd-archive

Description of Working Group:

The major purpose of this Group is to coordinate BGP deployment and
application in the current Internet.

It intends to create a forum for BGP users to share BGP deployment
experiences and also provide a channel for users to communicate with
router vendors who implemented or who are implementing BGP.  It also intends
to discuss BGP policy application and coordinate policy implementation
in the current internet routing environment which includes defining the
usage of policy, defining a mechanism to share policy information, etc.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 93 New     <draft-ietf-bgpdepl-minutes-93feb-00.txt>
                Notes of BGP-4/CIDR Coordination Meeting of 11 March 93

 Mar 93 New     <draft-nsfnet-aggregation-00.txt>
                Aggregation Support in the NSFNET Policy Routing Database

Benchmarking Methodology (bmwg)

Charter

Chair(s):
     Scott Bradner  <[e-mail]>

Operational Requirements Area Director(s)
     Scott Bradner  <[e-mail]>
     Bernhard Stockman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The major goal of the Benchmarking Methodology Working Group is to make a
series of recommendations concerning the measurement of the performance
characteristics of different classes of network equipment and software
services.

Each recommendation will describe the class of equipment or service,
discuss the performance characteristics that are pertinent to that
class, specify a suite of performance benchmarks that test the described
characteristics, as well as specify the requirements for common
reporting of benchmark results.

Classes of network equipment can be broken down into two broad
categories.  The first deals with stand-alone network devices such as
routers, bridges, repeaters, and LAN wiring concentrators.  The second
category includes host dependent equipment and services, such as network
interfaces or TCP/IP implementations.

Once benchmarking methodologies for stand-alone devices have matured
sufficiently, the Group plans to focus on methodologies for testing
system-wide performance, including issues such as the responsiveness of
routing algorithms to topology changes.

Internet Drafts:

  No Current Internet drafts.

Bridge MIB (bridge)

Charter

Chair(s):
     Fred Baker  <[e-mail]>

Network Management Area Director(s)
     Marshall Rose  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Bridge MIB Working Group is chartered to define a set of managed
objects that instrument devices that conform to the IEEE 802.1
standard for MAC-layer bridges.

This set of objects should be largely compliant with (and even draw
from) IEEE 802.1(b), although there is no requirement that any
specific object be present or absent.

The MIB object definitions produced will be for use by SNMP and will
be consistent with other SNMP objects, standards, and conventions.



Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 92 Oct 92  <draft-ietf-bridge-objects-01.txt>
                Definitions of Managed Objects for Bridges

Common Authentication Technology (cat)

Charter

Chair(s):
     John Linn  <[e-mail]>

Security Area Director(s)
     Stephen Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           bitsy.mit.edu:~/cat-ietf/archive

Description of Working Group:

The goal of the Common Authentication Technology Working Group is to
provide strong authentication to a variety of protocol callers in a
manner which insulates those callers from the specifics of underlying
security mechanisms.  By separating security implementation tasks from
the tasks of integrating security data elements into caller protocols,
those tasks can be partitioned and performed separately by
implementors with different areas of expertise.  This provides
leverage for the IETF community's security-oriented resources, and
allows protocol implementors to focus on the functions their protocols
are designed to provide rather than on characteristics of security
mechanisms.  CAT seeks to encourage uniformity and modularity in
security approaches, supporting the use of common techniques and
accommodating evolution of underlying technologies.

In support of these goals, the Working Group will pursue several
interrelated tasks.  We will work towards agreement on a common
service interface allowing callers to invoke security services, and
towards agreement on a common authentication token format,
incorporating means to identify the mechanism type in conjunction with
which authentication data elements should be interpreted.  The CAT
Working Group will also work towards agreements on suitable underlying
mechanisms to implement security functions; two candidate
architectures (Kerberos V5, based on secret-key technology and
contributed by MIT, and X.509-based public-key Distributed
Authentication Services being prepared for contribution by DEC) are
under current consideration.  The CAT Working Group will consult with
other IETF working groups responsible for candidate caller protocols,
pursuing and supporting design refinements as appropriate.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jun 91 Nov 92  <draft-ietf-cat-genericsec-03.txt, .ps>
                Generic Security Service Application Program Interface

 Jul 91 Sep 92  <draft-ietf-cat-kerberos-01.txt, .ps>
                The Kerberos Network Authentication Service (V5)

 Jul 91 Mar 93  <draft-ietf-cat-secservice-02.txt>
                Generic Security Service API : C-bindings

 Nov 91 Dec 92  <draft-ietf-cat-dass-01.txt, .ps>
                Distributed Authentication Security Service

 Apr 93 New     <draft-ietf-cat-ftpsec-00.txt>
                FTP Security Extensions

Chassis MIB (chassis)

Charter

Chair(s):
     Bob Stewart  <[e-mail]>
     Jeffrey Case  <[e-mail]>

Network Management Area Director(s)
     Marshall Rose  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

This Working Group will produce a document describing MIB objects for
use in a ``chassis'' --- which is a collection of traditionally
discrete network devices packaged in a single cabinet and power
supply.  A chassis may comprise, for example, combinations of layer 1
repeater elements, MAC layer bridges, or internetwork layer routers.

The Working Group is chartered to produce up to three distinct
documents that define extensions to the SNMP MIB:

(1) The Working Group is chartered to define MIB objects that represent
the mapping of the logical functions of traditional network devices
onto particular, physical hardware resources within the chassis.  These
MIB definitions will not address any aspects of the network functions
comprised by a chassis box that are shared with an analogous collection
of discrete network devices.

(2) The Working Group is chartered, at its option, to define MIB
objects that instrument the operational state of a power supply element
in a chassis.

(3) The Working Group is chartered, at its option, to define MIB
objects that represent aggregated information about collections of
network devices (e.g., aggregate information about devices attached to
a particular LAN), provided that this MIB specification is not specific
to chassis implementations of such networks and is also readily
implementable for analogous collections of discrete network devices.

The MIB object definitions produced will be for use by SNMP and will be
consistent with existing SNMP standards and framework.

Although the Working Group may choose to solicit input or expertise
from other relevant standards bodies, no extant standards efforts or
authorities are known with which alignment of this work is required.

Because the structure of chassis implementations varies widely, the
Working Group shall take special care that its definitions reflect a
generic and consistent architectural model of chassis management rather
than the structure of particular chassis implementations.

Should the Working Group elect to define objects representing
aggregated information about collections of network devices, those
efforts will not compromise the operational robustness of the SNMP that
depends on its realization of management system function as closely as
possible to centers of responsible authority.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jan 93 New     <draft-ietf-chassis-mib-00.txt>
                Definitions of Managed Objects for a Chassis Containing
                Multiple Logical Network Devices

Commercial Internet Protocol Security Option (cipso)

Charter

Chair(s):
     Ron Sharp  <[e-mail]>

Security Area Director(s)
     Stephen Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           [e-mail]

Description of Working Group:

The Commercial Internet Protocol Security Option Working Group is
chartered to define an IP security option that can be used to pass security
information within and between security domains.  This new security option
will be modular in design to provide developers with a single software
environment which can support multiple security domains.

The CIPSO protocol will support a large number of security domains.  New
security domains will be registered with the Internet Assigned Numbers
Authority (IANA) and will be available with minimal difficulty to all
parties.

There is currently in progress another IP security option referred to as
IPSO (RFC 1108).  IPSO is designed to support the security labels used by
the U.S. Department of Defense.  CIPSO will be designed to provide labeling for
the commercial, U.S. civilian and non-U.S. communities.

The Trusted Systems Interoperability Group (TSIG) has developed a document
which defines a structure for the proposed CIPSO option.  The Working Group
will use this document as a foundation for developing an IETF CIPSO
specification.



Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Dec 91 Aug 92  <draft-ietf-cipso-ipsecurity-01.txt>
                COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)

 Mar 93 New     <draft-ietf-cipso-ipsec-option-00.txt>
                COMMON IP SECURITY OPTION

Distributed File Systems (dfs)

Charter

Chair(s):
     Peter Honeyman  <[e-mail]>

Service Applications Area Director(s)
     Dave Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

Trans- and inter-continental distributed file systems are upon us.  The
consequences to the Internet of distributed file system protocol design and
implementation decisions are sufficiently dire that we need to investigate
whether the protocols being deployed are really suitable for use on the
Internet.  There's some evidence that the opposite is true, e.g., some
distributed file systems protocols don't checksum their data,
don't use reasonable MTUs, don't offer credible authentication or
authorization services, don't attempt to avoid congestion, etc.
Accordingly, a Working Group on DFS has been formed by the IETF. The
Working Group will attempt to define guidelines for ways that distributed file
systems should make use of the network, and to consider whether any
existing distributed file systems are appropriate candidates for
Internet standardization.  The Working Group will also take a look at the
various file system protocols to see whether they make data more vulnerable.
This is a problem that is especially severe for Internet users, and a
place where the IETF may wish to exert some influence, both on vendor
offerings and user expectations.


Internet Drafts:

  No Current Internet drafts.

Dynamic Host Configuration (dhc)

Charter

Chair(s):
     Ralph Droms  <[e-mail]>

Internet Area Director(s)
     Stev Knowles  <[e-mail]>
     David Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           sol.bucknell.edu:~/dhcwg

Description of Working Group:

The purpose of this Working Group is the investigation of network
configuration and reconfiguration management.  We will determine those
configuration functions that can be automated, such as Internet
address assignment, gateway discovery and resource location, and those
which cannot be automated (i.e., those that must be managed by network
administrators).

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 May 91 Sep 92  <draft-ietf-dhc-bootp-01.txt>
                Clarifications and Extensions for the Bootstrap Protocol

 Jul 91 Jan 93  <draft-ietf-dhc-protocol-06.txt, .ps>
                Dynamic Host Configuration Protocol

 Jun 92 Jan 93  <draft-ietf-dhc-options-03.txt>
                DHCP Options and BOOTP Vendor Extensions

 Jun 92 Jan 93  <draft-ietf-dhc-between-bootp-03.txt>
                Interoperation Between DHCP and BOOTP

Domain Name System (dns)

Charter

Chair(s):
     Rob Austein  <[e-mail]>

Service Applications Area Director(s)
     Dave Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           nicfs.nic.ddn.mil:~/namedroppers/*.Z

Description of Working Group:

The DNS Working Group is concerned with the design, operation, and
evolution of the Domain Name System within the Internet.  As the Internet
continues to grow, we expect to serve as a focal point for work on scaling
problems within the current framework, work on protocol evolution as new
mechanisms become necessary, and documentation of current practice for DNS
implementors and administrators.  We are also responsible for oversight of
DNS activities by other groups within the IETF to the extent that we
review the impact such work will have on the DNS and make recomendations
to the working groups and IESG as necessary.  Since some of these are
ongoing tasks, we do not expect the working group to disband anytime soon.

Several issues are of particular concern at this time:

Scaling.  The DNS is the victim of its own success.  The global DNS
namespace has grown to the point where administering the top levels of
the tree is nearly as much work as the old NIC host table used to be.
We need to work on ways to distribute the load.  Some of the solutions
are likely to be technical, some political or economic; we still treat
the top-level DNS service the way we did when DARPA was footing the
bill, and the funding for that service is in the process of going away.

Security.  The DNS is a zero-security system; it is not even as
strong as the IP layer above which it operates.  As a result,
accidental spoofing (cache pollution) is an all-too-frequent occurance.
We need to make the DNS more robust against accidental corruption, and
must provide at least an optional authentication mechanism for that
portion of the community that wants one.  At the same time, we must not
cripple the existing system by drasticly increasing its bandwidth
consumption or by mandating use of cryptographic techniques that would
preclude worldwide distribution of DNS software.  The global DNS
database is exactly that, an existing world-wide database representing
hosts on six continents and (at least) forty-five countries.  A
solution that does not take this into account is not acceptable.

Management.  We have a draft document describing MIB extensions to
manage the DNS.  We also need to specify a standard way to dynamically
create and destroy DNS records; SNMP may be an appropriate tool for
this task, but we haven't yet specified enough of the details to know
for certain.  We need to examine the impact that a dynamic update
mechanism will have on the DNS, with particular attention to security
and scaling issues.

IPv7/Routing.  As the fur starts flying in the battle between the IPv7
proponants and the new-routing-architecture proponants, we expect that
groups on both sides will need some amount of support from the DNS.
Such support is likely to be minimal and straightforward, but these
proposals are likely to need "rush service" for whatever support they
require.  So the working group needs to monitor these activities, stay
involved, and generally do what it can to make sure that DNS support is
not a bottleneck.

We also need to examine the impact that any proposed IPv7 system would
have on the DNS, since the DNS database and protocols have special
provision for IP addresses.



Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 92 Nov 92  <draft-ietf-dns-mibext-05.txt, .ps>
                DNS MIB Extensions

 Mar 93 New     <draft-ietf-dns-idpr-00.txt>
                DNS Support for IDPR

 Apr 93 New     <draft-ietf-dns-storage-00.txt, .ps>
                Using the Domain Name System To Store Arbitrary String
                Attributes

FDDI MIB (fddimib)

Charter

Chair(s):
     Jeffrey Case  <[e-mail]>

Network Management Area Director(s)
     Marshall Rose  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The FDDI MIB Working Group is chartered to define a MIB for FDDI
devices that is consistent with relevant FDDI specifications produced
by ANSI.  All definitions produced by this Working Group will be
consistent with the SNMP network management framework and other
internet-standard MIBs for SNMP.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 93 Mar 93  <draft-ietf-fddimib-objects-01.txt>
                FDDI Management Information Base

Host Resources MIB (hostmib)

Charter

Chair(s):
     Steven Waldbusser  <[e-mail]>

Network Management Area Director(s)
     Marshall Rose  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Host Resources MIB Working Group is chartered to produce exactly
one document that defines SNMP MIB objects that instrument
characteristics common to all internet hosts. The goal of this work is
to address the urgent operational need in the internet community for
management of host systems. Owing to this urgency, the Working Group
will focus exclusively on the alignment of existing MIB technology in
order to achieve common solutions in a timely manner.

For purposes of this effort, the term ``internet host'' is construed to
mean any computer that communicates with other similar computers
attached to the internet and that is directly used by one or more human
beings. Although the work of the Group does not necessarily apply to
devices whose primary function is communications services (e.g.,
terminal servers, routers, bridges, monitoring equipment), such
relevance is not explicitly precluded.  The single MIB produced shall
instrument attributes common to all internet hosts including, for
example, both personal computers and systems that run variants of
Unix.

The methodology of this Working Group is to focus entirely on the
alignment of existing, enterprise-specific MIBs for SNMP that are
relevant to its task. The Group will work towards its goal by
distillation and generalization of these existing MIBs into a single,
common MIB definition.

Owing to the urgent operational need for managing host systems, this
effort will not be comprehensive in scope. Rather, the MIB produced by
this Group will be confined to critical information about hardware and
software configuration, processor and memory use, and data storage
capacities, backup, and use.

Owing to the lack of a well-understood and accepted architecture, the
Working Group will not address in any way, mechanisms that could be used
to monitor or control the use of licensed software products.

All definitions produced by the Group will be consistent with the SNMP
network management framework and all other internet-standard MIBs for
SNMP.  Wherever possible, the definitions produced will make use of or
align with relevant work in progress with chartered working groups of
the IETF. Also, wherever possible, the Working Group will take into
consideration pre-existing, stable work produced by other, accredited
standards bodies.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 92 New     <draft-ietf-hostmib-resources-00.txt>
                Host Resources MIB

IEEE 802.3 Hub MIB (hubmib)

Charter

Chair(s):
     Keith McCloghrie  <[e-mail]>
     Donna McMaster  <[e-mail]>

Network Management Area Director(s)
     Marshall Rose  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           sweetwater.synoptics.com"~/pub/hubmib

Description of Working Group:

This Working Group will produce a document describing MIB objects for
use in managing Ethernet-like hubs.  A hub is defined as a multiport
repeater that conforms to Section 9, ``Repeater Unit for 10 Mb/s
Baseband Networks'' in the IEEE 802.3/ISO 8802-3 CSMA/CD standard (2nd
edition, Sept. 1990).  These Hub MIB objects may be used to manage
non-standard repeater-like devices, but defining objects to describe
vendor-specific properties of non-standard repeater-like devices are
outside the scope of this Working Group.  The MIB object definitions
produced will be for use by SNMP and will be consistent with other SNMP
objects, conventions, and definitions.

In order to minimize the instrumentation burden on managed agents, the
MIB definitions produced by the Working Group will, wherever feasible,
be semantically consistent with the managed objects defined in the IEEE
draft standard P802.3K, ``Layer Management for Hub Devices.''  The
Working Group will base its work on the draft that is the output of the
July 1991 IEEE 802 plenary meeting.  The Working Group will take
special cognizance of Appendix B of that specification that sketches a
possible realization of the relevant managed objects in the SNMP
idiom.

Consistent with the IETF policy regarding the treatment of MIB
definitions produced by other standards bodies, the Working Group may
choose to consider only a subset of those objects in the IEEE
specification and is under no obligation to consider (even for
``Optional'' status) all objects defined in the IEEE specification.
Moreover, when justified by special operational needs of the community,
the Working Group may choose to define additional MIB objects that are
not present in the IEEE specification.

Although the definitions produced by the Working Group should be
architecturally consistent with MIB-II and related MIBs wherever
possible, the Charter of the Working Group does not extend to
perturbing the conceptual models implicit in MIB-II or related MIBs in
order to accommodate 802.3 Hubs.  In particular, to the extent that the
notion of a ``port'' in an 802.3 Hub is not consistent with the notion
of a network ``interface'' as articulated in MIB-II, it shall be
modelled independently by objects defined in the Working Group.

Because the structure of 802.3 Hub implementations varies widely, the
Working Group shall take special care that its definitions reflect a
generic and consistent architectural model of Hub management rather
than the structure of particular Hub implementations.

The IEEE Hub Management draft allows an implementor to separate the ports in a hub into groups, if desired (i.e., a vendor might choose to represent field-replaceable unites as groups of ports so that the port numbering would match a modular hardware implementation.)  Because the Working Group Charter
does not extend to consideration of fault-tolerant, highly-available systems
in general, its treatment of these groups of ports in an 802.3 Hub (if any)
shall be specific to Hub management and without impact upon other portions of
the MIB.

The Working Group is further chartered at its discretion to define an
SNMP MIB for management of IEEE 802.3 Medium Access Units (MAUs).  An
802.3 Medium Attachment Unit (MAU) attaches a repeater port or
Ethernet-like interface to the local network medium. The scope of this
work may include several types of MAU units: 10BASE5 (thick coax),
10BASE2 (thin coax), 10BASE-T (twisted pair), FOIRL and 10BASE-F (fiber
optic).  Managed objects defined as part of the MAU MIB task may, for
example, represent such information as MAU type, link status, and
jabbering indications.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 93 Mar 93  <draft-ietf-hubmib-mau-01.txt>
                Definitions of Managed Objects for IEEE 802.3 Medium Attachment
                Units (MAUs)

Internet Anonymous FTP Archives (iafa)

Charter

Chair(s):
     Peter Deutsch  <[e-mail]>
     Alan Emtage  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           archive.cc.mcgill.ca:~/pub/iafa-archive

Description of Working Group:

The Internet Anonymous FTP Archives Working Group is chartered to
define a set of recommended standard procedures for the access and
administration of anonymous ftp archive sites on the Internet.  Such a
set of procedures will provide a framework for:

(a) Allowing the inexperienced Internet user the ability to more
    easily navigate the hundreds of publically accessible archive sites.

(b) Allowing users and network-based tools to retrieve specific site
    information such as access policies, contact information, possible
    areas of information specialization, archived package descriptions, etc.,
    in a standardized manner.

Particular emphasis will be placed on the possible impact of these
procedures on the FTP site administrators.

Attention will be paid to the impact of newer archive indexing and
access tools on the operation of such archive sites. A set of
suggestions will be offered to allow archive site administrators to
better integrate their offerings with such tools as they are
developed.

The security of the anonymous FTP site configuration will also be
considered to be an integral part of this document. It is expected
that remote management of the archives will be adequately handled by
existing network management procedures.


Internet Drafts:

  No Current Internet drafts.

Inter-Domain Policy Routing (idpr)

Charter

Chair(s):
     Martha Steenstrup  <[e-mail]>

Routing Area Director(s)
     Robert Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Inter Domain Policy Routing Working Group is chartered to
develop an architecture and set of protocols for policy routing
among large numbers of arbitrarily interconnected administrative
domains.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Feb 90 Jun 92  <draft-ietf-idpr-architecture-05.txt, .ps>
                An Architecture for Inter-Domain Policy Routing

 Mar 91 Jun 92  <draft-ietf-idpr-specv1-02.txt, .ps>
                Inter-Domain Policy Routing Protocol Specification:  Version 1

 Jul 91 Mar 93  <draft-ietf-idpr-mib-02.txt>
                Definitions of Managed Objects for the Inter-Domain Policy
                Routing Protocol (Version 1)

 Apr 92 New     <draft-ietf-idpr-summary-00.txt, .ps>
                IDPR as a Proposed Standard

Integrated Directory Services (ids)

Charter

Chair(s):
     Chris Weider  <[e-mail]>
     Tim Howes  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           merit.edu:~/pub/ids-archive

Description of Working Group:

The Integrated Directory Services Working Group (IDS) is chartered to
facilitate the integration and interoperability of current and future
directory services into a unified directory service. This work will
unite directory services based on a heterogeneous set of directory
services protocols (X.500, WHOIS++, etc.). In addition to specifying
technical requirements for the integration, the IDS Group will also
contribute to the administrative and maintenance issues of directory
service offerings by publishing guidelines on directory data integrity,
maintenance, security, and privacy and legal issues for users and
administrators of directories.

IDS will also assume responsibility for the completion of the
outstanding Directory Information Services Infrastructure (DISI)
Internet-Drafts, which are all specific to the X.500 protocol, and for
the maintenance of FYI 11, ``A catalog of available X.500
implementations''.

IDS will need to liase with the groups working on development and
deployment of the various directory service protocols.

The IDS Working Group is a combined effort of the Applications Area and
the User Services Area of the IETF.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 92 Mar 93  <draft-ietf-ids-x500-survey-01.txt>
                A Survey of Advanced Usages of X.500

Integration of Internet Information Resources (iiir)

Charter

Chair(s):
     Chris Weider  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           merit.edu:~/pub/iiir-archive

Description of Working Group:

The Integration of Internet Information Resources Working Group (IIIR)
is chartered to facilitate interoperability between Internet
Information Services, and to develop, specify, and align protocols
designed to integrate the plethora of Internet information services
(WAIS, ARCHIE, Prospero, etc.) into a single ``virtually unified
information service'' (VUIS). Such protocols would include (but are not
limited to) update protocols for distributed servers, a `query routing
protocol' to pass queries between existing services, protocols for
gateways between existing and future services, and standard exchange
formats (perhaps based on Z39.50) for cross-listing specific
information.

Also, where necessary, IIIR will create technical documentation for
protocols used for information services in the Internet.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 93 New     <draft-ietf-iiir-transponders-00.txt>
                Resource Transponders

 Mar 93 New     <draft-ietf-iiir-vision-00.txt>
                A Vision of an Integrated Internet Information Service

IP Address Encapsulation (ipae)

Charter

Chair(s):
     Dave Crocker  <[e-mail]>

Internet Area Director(s)
     Stev Knowles  <[e-mail]>
     David Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           parcftp.xerox.com:~/pub/ip-encaps/

Description of Working Group:

The IPAE Working Group seeks to develop a capability for extending IP to
support larger addresses while minimizing impact on the installed base of IP
users.  An enhancement to the current system is mandatory due to the
limitations of the current 32 bit IP addresses.  IPAE seeks to upgrade the
current system, rather than to replace the Internet Protocol.  The approach
taken will be to sandwhich a small addressing layer, above IP but below TCP
or UDP, with the new layer having its own IP Protocol-ID.  This special layer
will thereby encapsulate new, larger, globally-unique addresses for source
and destination, as well as any other fields of information that are
considered essential.

The specificaton effort will attend to issues of transition and coexistance,
among unmodified ``IP'' hosts and hosts which support ``IPAE'' hosts The
IPAE approach will develop a framework to organize the Internet into areas
called ``IP Addressing Commonwealths'' within which 32-bit IP addresses are
unique and are part of a larger, globally-unique Internet addressing scheme.
It is a goal of this effort to avoid requiring any router within a
Commonwealth to be modified, but any host wishing full Internet connectivity
will need to support IPAE eventually.  Further, any system wishing to support
full IPAE addresses will need to be modified, including network management
software.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 92 New     <draft-ietf-ipae-ipv7-criteria-00.txt>
                IPv7 Criteria Analysis for IP Address Encapsulation (IPAE) and
                the Simple Internet Protocol (SIP)

 Nov 92 New     <draft-ietf-ipae-new-ip-00.txt>
                IP Address Encapsulation (IPAE): A Mechanism for Introducing a
                New IP

OSI IDRP for IP over IP (ipidrp)

Charter

Chair(s):
     Sue Hares  <[e-mail]>

Routing Area Director(s)
     Robert Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           merit.edu:~/pub/archive/idrp

Description of Working Group:

The IDRP for IP over IP Working Group is chartered to standardize and promote
the use of IDRP (ISO Inter-Domain Routing Protocol) as a scalable inter-
autonomous system routing protocol capable of supporting Policy Based Routing
for TCP/IP internets.  The objective is to take IDRP, as it is defined by ISO
standards, and to define backward compatible extensions and/or network
adaptation layers to enable this protocol to be used in the TCP/IP internets.
If any ISO standardization efforts overlap this area of work, it is intended
that the ISO work will supersede the standards proposed by this Group.

1) IDRP for IP over IP document (standards track)

   This document contains the appropriate adaptations of the IDRP protocol
   definition that enables it to be used as a protocol for exchange of
   ``inter-autonomous system information'' among routers to support
   forwarding of IP packets across multiple autonomous systems.

2) IDRP MIB document (standards track)

   This document contains the MIB Definitions for IDRP.  These MIB
   Definitions are done in two parts; IDRP General MIB, and IDRP for  IP
   MIB. An appendix is planned; IDRP For IP GDMO

3) IDRP - OSPF Interactions (standards track)

   This document will specify the interactions between IDRP and OSPF.
   This document will be based on a combination of BGP-OSPF interactions
   document and IDRP - ISIS interaction document.

4) IDRP for IP Usage document (standards track)

   Most of the IDRP for IP Usage will reference the CIDR  (Supernetting
   document) Internet Draft.  Any additional terms or protocol definitions
   needed for IDRP for IP will also be specified here.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 93 New     <draft-ietf-ipidrp-sip-00.txt>
                IDRP for SIP

IP over Large Public Data Networks (iplpdn)

Charter

Chair(s):
     George Clapp  <[e-mail]>

Internet Area Director(s)
     Stev Knowles  <[e-mail]>
     David Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ietf.cnri.reston.va.us:~/ietf-mail-archive/iplpdn/*

Description of Working Group:

The IP over Large Public Data Networks Working Group will
specify the operation of the TCP/IP protocol suite over Public Data
Networks (PDNs) such as SMDS, ISDN, X.25 PDNs, and Frame Relay.  The
Working Group will develop and define algorithms for the resolution of
IP addresses and for the routing of IP datagrams over large,
potentially global, public data networks.

The IP over SMDS Working Group has defined the operation of the
Internet protocols when SMDS is used to support relatively small
virtual private networks, or Logical IP Subnets (LISs).  Issues
arising from public and global connectivity were delegated to the
IPLPDN Working Group.

The IPLPDN Working Group will also continue the work of the Private Data Network
Routing Working Group (PDNROUT) on X.25 PDNs.  This work will be
extended to include call management and the use of the ISDN B channels
for the transport of IP datagrams.

Address resolution and routing over Frame Relay will also be
discussed.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jun 92 Jan 93  <draft-ietf-iplpdn-shortcutrouting-02.txt>
                Shortcut Routing: Discovery and Routing over Large Public Data
                Networks

 Jan 93 Mar 93  <draft-ietf-iplpdn-framerelay-01.txt>
                Multiprotocol Interconnect over Frame Relay Networks

 Feb 93 New     <draft-ietf-iplpdn-multi-isdn-00.txt>
                The Transmission of Multi-protocol Datagrams over Circuit-mode
                ISDN

 Feb 93 New     <draft-ietf-iplpdn-para-negotiation-00.txt>
                Parameter Negotiation for the Multiprotocol Interconnect

 Mar 93 New     <draft-ietf-iplpdn-frmib-dte-00.txt>
                Management Information Base for Frame Relay DTEs

ISIS for IP Internets (isis)

Charter

Chair(s):
     Ross Callon  <[e-mail]>
     Chris Gunner  <[e-mail]>

Routing Area Director(s)
     Robert Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The IETF ISIS Working Group will develop additions to the existing
OSI IS-IS Routing Protocol to support IP environments and dual (OSI
and IP) environments.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 91 Mar 93  <draft-ietf-isis-mib-02.txt>
                Integrated IS-IS Management Information Base

 Jan 93 New     <draft-ietf-isis-tcpip-00.txt, .ps>
                Use of OSI IS-IS for Routing in TCP/IP and Multi-Protocol
                Environments

Internet School Networking (isn)

Charter

Chair(s):
     John Clement  <[e-mail]>
     Arthur St. George  <[e-mail]>
     Connie Stout  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe isn-wg <first name> <last name>
     Archive:

Description of Working Group:

The Internet School Networking Working Group is chartered to
facilitate the connection of the United States' K-12
(Kindergarten-12th Grade) schools, public and private, to the
Internet, and school networking in general.

It is critically important that national networking for K-12 education
proceed along established lines of protocol, using existing network
structures.  The Working Group's first priority will be to establish
guidelines for specialized user interfaces.  K-12 networking will also
require other support services, such as directories, online and
hotline help, specialized training programs and collaborative projects
with instructional and curriculum groups, disciplinary groups and
postsecondary institutions.

While the initial focus is school networking in the U.S., the Working
Group will coordinate its efforts with similar activities in other
countries and regions of the world.


Internet Drafts:

  No Current Internet drafts.

MHS-DS (mhsds)

Charter

Chair(s):
     Kevin Jordan  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

Service Applications Area Director(s)
     Dave Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           mercury.udev.cdc.com:~/pub/archives/mhs-ds-archive

Description of Working Group:

The MHS-DS Working Group works on issues relating to Message Handling
Services use of Directory Services.  The Message Handling Services are
primarily X.400, but issues relating to RFC822 use of Directory and
Directory support for RFC822 and X.400 interworking are in the scope of
the Group.  Directory and Directory Services refer to the services
based upon the CCITT X.500 recommendations and additional ISO
standards, stable implementation agreements, and RFCs, as specified by
the OSI-DS Working Group.  The major aims of the MHS-DS working group
are:

1. Define a set of specifications to enable effective, large-scale
deployment of X.400.

2. Study issues associated with supporting X.400 communities which lack
access to X.500 Directory, and define requirements for tools which: a)
extract information from the X.500 Directory for use by non-X.500
applications, b) upload information into the X.500 Directory.

3. Coordinate a pilot project which deploys MHS information into the
X.500 Directory and uses it to facilitate mail routing and address
mapping.  The results of this pilot will be documented, and experience
gained from the project will be fed back into the Internet
specifications created by the working group.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Apr 92 Nov 92  <draft-ietf-mhsds-822dir-02.txt, .ps>
                Use of the Directory to support routing for RFC 822 and related
                protocols

 Apr 92 Nov 92  <draft-ietf-mhsds-mhsprofile-02.txt, .ps>
                A simple profile for MHS use of Directory

 Apr 92 Nov 92  <draft-ietf-mhsds-subtrees-02.txt, .ps>
                Representing Tables and Subtrees in the Directory

 Apr 92 Nov 92  <draft-ietf-mhsds-infotree-02.txt, .ps>
                Representing the O/R Address hierarchy in the Directory
                Information Tree

 Apr 92 Nov 92  <draft-ietf-mhsds-supmapping-02.txt, .ps>
                Use of the Directory to support mapping between X.400 and RFC
                822 Addresses

 Apr 92 Nov 92  <draft-ietf-mhsds-mhsuse-02.txt, .ps>
                MHS use of the Directory to support distribution lists

 Apr 92 Nov 92  <draft-ietf-mhsds-routdirectory-02.txt, .ps>
                MHS use of Directory to support MHS Routing

 Nov 92 New     <draft-ietf-mhsds-convert-00.txt, .ps>
                MHS use of Directory to support MHS Content Conversion

MIME-MHS Interworking (mimemhs)

Charter

Chair(s):
     Steve Thompson  <[e-mail]>

Applications Area Director(s)
     Brewster Kahle  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

MIME, (Multipurpose Internet Mail Extensions) is currently a Proposed Standard. MIME redefines the format of message bodies to allow multi-part textual
and non-textual message bodies to be represented and exchanged without
loss of information.  With the introduction of MIME as a Proposed
Standard it is now possible to define mappings between RFC-822
content-types and X.400 body parts.  The MIME-MHS Interworking Working Group is
chartered to develop these mappings, providing an emphasis on both
interworking between Internet and MHS mail environments and also on
tunneling through these environments. These mappings will be made in
the context of an RFC-1148bis environment.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 92 Mar 93  <draft-ietf-mimemhs-mapping-02.txt>
                Mapping between X.400 and RFC-822 Message Bodies

 Jul 92 Nov 92  <draft-ietf-mimemhs-body-equival-02.txt>
                Equivalences between 1988 X.400 and RFC-822 Message Bodies

 Sep 92 Feb 93  <draft-ietf-mimemhs-harpoon-01.txt>
                HARPOON:  Rules for downgrading messages from X.400/88 to
                X.400/84 when MIME content-types are present in the messages


Multicast Extensions to OSPF (mospf)

Charter

Chair(s):
     Steve Deering  <[e-mail]>

Routing Area Director(s)
     Robert Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

This Working Group will extend the OSPF routing protocol so that it
will be able to efficiently route IP multicast packets.  This will
produce a new (multicast) version of the OSPF protocol, which will be
as compatible as possible with the present version (packet formats and
most of the algorithms will hopefully remain unaltered).

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 91 Mar 93  <draft-ietf-mospf-multicast-03.txt, .ps>
                Multicast Extensions to OSPF

 Nov 92 Jan 93  <draft-pusateri-tokenring-lan-02.txt>
                IP Multicast over Token-Ring Local Area Networks

Network Access Server Requirements (nasreq)

Charter

Chair(s):
     Allan Rubens  <[e-mail]>
     John Vollbrecht  <[e-mail]>

Security Area Director(s)
     Stephen Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:


The Network Access Server Requirements Working Group has as its primary
goal, to identify functions and services that should be present in IP
Network Access Servers (NAS's) and to specify the standards that
provide for these functions and services.  The term ``Network Access
Server'' is used instead of the more conventional term ``Terminal Server''
as it more accurately describes the functions of interest to this
Group.  A ``Network Access Server'' is a device that provides for the
attachment of both traditional ``dumb terminals'' and terminal emulators
as well as workstations, PC's or routers utilizing a serial line
framing protocol such as PPP or SLIP.  A NAS is viewed as a device that
sits on the boundary of an IP network, providing serial line points of
attachment to the network.  A NAS is not necessarily a separate
physical entity; for example, a host system supporting serial line
attachments is viewed as providing NAS functionality and should abide
by NAS requirements.

This Group will adopt (or define, if need be) a set of standard
protocols to meet the needs of organizations providing network access.
The immediate needs to be addressed by the Group are in the areas of
authentication, authorization, and accounting (AAA). In general, this
Group will select a set of existing standards as requirements for a
NAS.  If necessary, the Group will identify areas of need where
internet standards don't already exist and new standardization efforts
may be required.

Initially the Group will independently investigate the two cases of
character and frame oriented access to the NAS.  This investigation
will be aimed at determining what work is being done, or needs to be
done, in this and other working groups in order to be able to define
the set of NAS requirements.  While the ultimate goal of this Group is
to produce a NAS Requirements document, it may be necessary to define
standards as well.  This initial investigation will help determine what
the goals of this Group need to be.  The Group will also work with
appropriate Working Groups to define required NAS standards that fall
into the areas of these other groups.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 92 New     <draft-ietf-nasreq-nasrequirements-00.txt>
                Network Access Server Proposed Requirements Document

Network Database (netdata)

Charter

Chair(s):
     Daisy Shen  <[e-mail]>

Applications Area Director(s)
     Brewster Kahle  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Network Database Working Group is chartered to define a standard
interface among databases on TCP/IP networks.  The Working Group will
address the issue of database connectivity in a distributed environment
which allows authorized users remote access to databases.  It will be
designed as a client/server model based on TCP/IP as its communication
protocol.

Several problems must be resolved that are associated with the network
database protocol, such as management of multiple threads between
clients and servers, management of multiple servers, management of data
buffers, data conversions, and security.

Additional related problems will be covered as the discussion goes on.
Therefore, the description and the schedule can be revised.

This Working Group is independent from the SQL access group; however,
there may be some overlapping interest.  The SQL access group is welcome
to join IETF's discussions and share information in both directions.
If both groups find that merging two efforts into one will speed up the
process, the merge can be done in the future.  For now, this Working
Group works on issues according to its own schedule and efforts.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jun 91 Feb 93  <draft-ietf-netdata-netdata-04.txt>
                Network Database Protocol

 Dec 91 Feb 93  <draft-ietf-netdata-implement-03.txt>
                Network Database Implementation Information Internet Draft

Networked Information Retrieval (nir)

Charter

Chair(s):
     Jill Foster  <[e-mail]>
     George Brett  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe nir <first name> <last name>
     Archive:           mailbase.ac.uk:~/pub/nir

Description of Working Group:

As the network has grown, along with it there has been an increase in
the number of software tools and applications to navigate the network
and make use of the many, varied resources which are part of the
network.  Within the past year and a half we have seen a wide spread
adoption of tools such as the ARCHIE servers, the Wide Area Information
Servers (WAIS), the Internet Gopher, and the WorldWide Web (WWW).  In
addition to the acceptance of these tools there are also diverse
efforts to enhance and customize these tools to meet the needs of
particular network communities.

There are many organizations and associations that have recently begun
to focus on the proliferating resources and tools for networked
information retrieval (NIR).  The Networked Information Retrieval Group
will be a cooperative effort of three major players in the field of
NIR: IETF, RARE, and the Coalition for Networked Information (CNI)
specifically tasked to collect and disseminate information about the
tools and to discuss and encourage cooperative development of current
and future tools.

The NIR Working Group intends to increase the useful base of
information about networked information retrieval (NIR) tools, their
developers, interested organizations, and other activities that relate
to the production, dissemination, and support of NIR tools, to produce
documentation that will enable user services organizations to provide
better support for NIRtools, to develop materials that will assist the
support and training of end users and to evolve in the future as
necessary to meet and anticipate changes in the field (i.e., NIR
tools, protocols, network topology, etc.)

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 93 New     <draft-ietf-nir-status-report-00.txt>
                A Status Report on Networked Information Retrieval: Tools and
                Groups

Network Information Services Infrastructure (nisi)

Charter

Chair(s):
     April Marine  <[e-mail]>
     Pat Smith  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The NISI Working Group will explore the requirements for common, shared
Internet-wide network information services. The goal is to develop an
understanding for what is required to implement an information services
``infrastructure'' for the Internet.  The work will begin with existing NIC
functions and services and should build upon work already being done within the
Internet community.  It should address areas such as common information
formats, methods of access, user interface, and issues relating to security and
privacy of Internet databases.


Internet Drafts:

  No Current Internet drafts.

Network Joint Management (njm)

Charter

Chair(s):
     Gene Hastings  <[e-mail]>

Operational Requirements Area Director(s)
     Scott Bradner  <[e-mail]>
     Bernhard Stockman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

There is a need for many different kinds of efforts to deal with
operational and front line engineering issues, including helping the
disparate organizations work with each other.  This is an attempt to
solidify some of those topics.  This does not make any pretense of being
exhaustive.

Area of interest:  Operational issues and developments of the Internet.

Membership:  Operations and engineering personnel from national backbone
and mid-level networks.  Other groups with responsibility for production
oriented services such as security oriented groups.

Associated Technical groups:  Groups which will have an interest in, and
input to the Agenda of this Group will include the IAB and its task
forces, and groups within FARNET. In particular FARNET has now several
technical issues of concern, such as the selection of standard
inter-network services for debugging (like maps and standard SNMP
communities), and the specification of standard network statistics to be
taken (of special concern is the ubiquitous ability to collect those
statistics).

Meeting Times:  Members of the Group will represent organizations with
production responsiblities.  Most work will be carried on via email or
teleconferencing.

Internet Drafts:

  No Current Internet drafts.

Network News Transport Protocol (nntp)

Charter

Chair(s):
     Eliot Lear  <[e-mail]>

Applications Area Director(s)
     Brewster Kahle  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

This Group will study and review the issues involved with netnews
transport over the Internet.  Originally released as an RFC in
February of 1986, NNTP is one of the widest implementations of an
elective status protocol.  As of this writing, the protocol has just
passed its fifth birthday, not having been updated once.

Over the years several enhancements have been suggested, and several
have even been implemented widely.  The intent of this Working Group
will be to encode the more popular and plausible enhancements into an
Internet standard.  Included in the initial list of changes to be
considered are the following:

(1) User level and site designated authentication methods;
(2) Binary transfer capability;
(3) Minimization of line turnaround; and
(4) Stronger article selection capability.

It is expected that public domain software will be released
concurrently with an RFC, demonstrating the protocol enhancements.



Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Sep 91 Dec 92  <draft-ietf-nntp-news-01.txt, .ps>
                Network News Transfer Protocol Version 2:  A Protocol for the
                Stream-Based Transmission of News


Network OSI Operations (noop)

Charter

Chair(s):
     Susan Hares  <[e-mail]>
     Cathy Wittbrodt  <[e-mail]>

Operational Requirements Area Director(s)
     Scott Bradner  <[e-mail]>
     Bernhard Stockman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           merit.edu:~/pub/noop-archive

Description of Working Group:

The Working Group is chartered to work on issues related to the
deployment of CLNP in the Internet.  The first area of this Group's
work has been the learning necessary to start deploying OSI in
internet networks.  This phase includes planning for OSI
deployment by creating routing plans for regional networks and
education on using OSI routing protocols.

This first area of the Group's work will be on-going as we continue to
deploy OSI in the Internet.  This step has lead to people deploying
OSI for Pilot projects and demonstrations of OSI.

The second step of deploying OSI will be the transition of OSI from a
pilot service to a production service.  During this phase we will work
on specifying the network debugging tools and test beds.  We will need
to track the level of OSI support in the Internet.  We will need to
provide documentation for new users of OSI on the Internet.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 92 Feb 93  <draft-ietf-noop-echo-01.txt>
                An Echo Function for ISO 8473

 Nov 92 Mar 93  <draft-ietf-noop-tools-01.txt>
                Essential Tools for the OSI Internet

 Mar 93 New     <draft-ietf-noop-osi-tools-00.txt>
                Essential Tools for the OSI Internet

Network Printing Protocol (npp)

Charter

Chair(s):
     Glenn Trewitt  <[e-mail]>

Applications Area Director(s)
     Brewster Kahle  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Network Printing Working Group has the goal of pursuing those
issues which will facilitate the use of printers in an internetworking
environment.  In pursuit of this goal it is expected that we will
present one or more printing protocols to be considered as standards
in the Internet community.

This Working Group has a number of specific objectives.  To provide a
draft RFC which will describe the LPR protocol.  To describe printing
specific issues on topics currently under discussion within other
Working Groups (e.g., Security and Dynamic Host Configuration), to
present our concerns to those Working Groups, and to examine printing
protocols which exist or are currently under development and assess
their applicability to Internet-wide use, suggesting changes if
necessary.


Internet Drafts:

  No Current Internet drafts.

Office Document Architecture (oda)

Charter

Chair(s):
     Peter Kirstein  <[e-mail]>

Applications Area Director(s)
     Brewster Kahle  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The ODA Working Group will develop guidelines for the use of the Office
Document Architecture for the  exchange of Compound documents including
formattable text, bit-map graphics and geometric graphics according to
the ODA Standard.  It will  consider  also Intercept Standards for other
document  content types it considers vital - e.g.,  spreadsheets.  The
Working Group will  define  how to use  both SMTP and X.400  for
interchange of ODA documents.   It will maintain close liaison with the SMTP
and X.400 Working Groups.

This Working Group will review the availability of ODA implementations, in
order to mount a Pilot Testbed for processable compound document
interchange.  Finally, it will set up and evaluate such a testbed.



Internet Drafts:

  No Current Internet drafts.

Operational Statistics (opstat)

Charter

Chair(s):
     Bernhard Stockman  <[e-mail]>
     Phillip Gross  <[e-mail]>

Operational Requirements Area Director(s)
     Scott Bradner  <[e-mail]>
     Bernhard Stockman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           wuarchive.wustl.edu:~doc/mailing-lists/oswg-l

Description of Working Group:

Today  there exist a  variety of network  management tools for
the collection and presentation  of network statistical  data.
Different kinds  of measurements  and  presentation techniques
makes it hard to compare data between networks.  There exists a
need to compare these statistical data on  a uniform  basis to
facilitate cooperative management,  ease problem isolation  and
network planning.

The Working Group will  try  to   define a  model for  network
statistics,   a minimal set   of  common  metrics,   tools for
gathering  statistical  data, a  common  statistical  database
storage format and  common presentation   formats.  Collecting
tools will store data in a given  format later to be retrieved
by presentation tools displaying the data in a predefined way.


Internet Drafts:

  No Current Internet drafts.

OSI Directory Services (osids)

Charter

Chair(s):
     Steve Kille  <[e-mail]>

Applications Area Director(s)
     Brewster Kahle  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The OSI-DS Group works on issues relating to building an OSI Directory
Service using X.500 and its deployment on the Internet.  Whilst this
Group is not directly concerned with piloting, the focus is practical,
and technical work needed as a pre-requisite to deployment of an open
Directory will be considered.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 90 Jan 93  <draft-ietf-osids-friendlynaming-05.txt, .ps>
                Using the OSI Directory to Achieve User Friendly Naming

 Jan 92 Jan 93  <draft-ietf-osids-distnames-05.txt, .ps>
                A String Representation of Distinguished Names

 Apr 92 Jan 93  <draft-ietf-osids-lightdirect-03.txt>
                Lightweight Directory Access Protocol

 May 92 Aug 92  <draft-ietf-osids-syntaxes-01.txt>
                The String Representation of Standard Attribute Syntaxes

 Sep 92 New     <draft-ietf-osids-dsa-metrics-00.txt>
                DSA Metrics

Open Shortest Path First IGP (ospf)

Charter

Chair(s):
     Mike Petry  <[e-mail]>
     John Moy  <[e-mail]>

Routing Area Director(s)
     Robert Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The OSPF Working Group will develop and field test an SPF-based
Internal Gateway Protocol.  The specification will be published and
written in such a way so as to encourage multiple vendor
implementations.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 91 Feb 93  <draft-ietf-ospf-trapmib-02.txt>
                OSPF Version 2 Traps

 Oct 92 New     <draft-ietf-ospf-nssa-option-00.txt>
                The OSPF NSSA Option

 Nov 92 New     <draft-ietf-ospf-mib-00.txt>
                OSPF Version 2 Management Information Base

 Nov 92 Mar 93  <draft-ietf-ospf-version2-01.txt, .ps>
                OSPF Version 2

 Mar 93 New     <draft-ietf-ospf-extattr-00.txt>
                The OSPF External Attributes LSA

Privacy-Enhanced Electronic Mail (pem)

Charter

Chair(s):
     Stephen Kent  <[e-mail]>

Security Area Director(s)
     Stephen Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           [e-mail]

Description of Working Group:

PEM is the outgrowth of work by the Privacy and Security
Research Group (PSRG) of the IRTF.  At the heart of PEM is a set of
procedures for transforming RFC 822 messages in such a fashion as to
provide integrity, data origin authenticity, and optionally,
confidentiality.  PEM may be employed with either symmetric or
asymmetric cryptographic key distribution mechanisms.  Because the
asymmetric (public-key) mechanisms are better suited to the large
scale, heterogeneously administered environment characteristic of the
Internet, to date only those mechanisms have been standardized.  The
standard form adopted by PEM is largely a profile of the CCITT X.509
(Directory Authentication Framework) recommendation.

PEM is defined by a series of documents.  The first in the
series defines the message processing procedures.  The second defines
the public-key certification system adopted for use with PEM.
The third provides definitions and identifiers for various
algorithms used by PEM.  The fourth defines message formats and conventions for
user registration, Certificate Revocation List (CRL) distribution,
etc.  (The first three of these were previously issued as RFCs 1113,
1114 and 1115.  All documents have been revised and are being issed
first as Internet Drafts.)


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 92 Mar 93  <draft-ietf-pem-mime-01.txt>
                MIME-PEM Interaction

P. Internet Protocol (pip)

Charter

Chair(s):
     Paul Francis  <[e-mail]>

Internet Area Director(s)
     Stev Knowles  <[e-mail]>
     David Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           thumper.bellcore.com:~/pub/tsuchiya/pip-archive

Description of Working Group:

The PIP Working Group is chartered to develop an IPv7 proposal using
the basic ideas of Pip as described in the Pip overview.

Pip is designed on one hand to be very general, being able to handle
many routing/addressing/flow paradigms, but on the other hand to allow
for relatively fast forwarding.  Pip has the potential to allow for
better evolution of the internet.  In particular, it is hoped that we
will be able to advance routing, addressing, and flow techniques
without necessarily having to change hosts (once hosts are running
Pip).

While the Pip overview demonstrates a number of powerful mechanisms,
much work remains to be done to bring Pip to a full specification.
This work includes, but is not limited to: specifying the header
format; specifying a basic set of error messages (PCMP messages);
specifying the Pip forwarding rules; specifying host interface messages
(particularly the directory service query response); specifying rules
for host Pip header construction; specifying modifications to existing
protocols for use with Pip (BGP IV, OSPF, ARP, DNS, etc.); specifying
Pip MAX MTU Discovery techniques; and specifying a transition strategy
for Pip.

Over the near-term, the goal of the PIP Working Group will be to produce these
specifications and supporting documentation.  Over the long-term, up to
the point where Pip is definitively rejected as IPv7, it is expected
that the PIP Working Group will oversee implementations and testing of the Pip
specifications.

Except to the extent that the PIP Working Group modifies existing protocols for
operation with Pip, and to the extent that the PIP Working Group must be aware of routing/addressing/flow architectures to really make Pip general, the
PIP Working Group will not work on routing/addresing/flow architectures.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 92 Feb 93  <draft-ietf-pip-processing-01.txt>
                Pip Header Processing

 Nov 92 New     <draft-ietf-pip-eip-shell-00.txt>
                The EIPIP Protocol: a Pip engine with an EIP shell

 Nov 92 New     <draft-wang-transition-00.txt>
                Transition to the Future Internet Protocol a comparison of
                three transition schemes

 Nov 92 Jan 93  <draft-ietf-pip-identifiers-01.txt>
                Pip Identifiers

 Nov 92 New     <draft-ietf-pip-ipv7-analysis-00.txt>
                IPv7 Criteria Analysis for EIPIP

 Jan 93 New     <draft-ietf-pip-dns-00.txt>
                Use of DNS with Pip

 Feb 93 New     <draft-ietf-pip-architecture-00.txt>
                Pip Near-term Architecture

 Mar 93 New     <draft-ietf-pip-provider-addr-00.txt>
                On the Assignment of Provider Rooted Addresses

 Apr 93 New     <draft-ietf-pip-vector-00.txt>
                The Multi-Level Path Vector Routing Scheme

Process for Organization of Internet Standards (poised)

Charter

Chair(s):
     Steve Crocker  <[e-mail]>

None Director(s)
     Phill Gross  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ietf.cnri.reston.va.us:~/ietf-mail-archive/poised/*

Description of Working Group:

       The goal of this Working Group is to examine the Internet
       standards process and the responsibilities of the IAB, with
       attention to the relationship between the IAB and IETF/IESG.

       The need for this Working Group was suggested during discussions
       at the July 1992 IETF.  This led to a request from the Internet
       Society president to form such a Working Group.

       The Working Group will consider the following matters:

         1. Procedures for making appointments to the Internet
            Architecture Board.

         2. Procedures for resolving disagreements among IETF, IESG and
            IAB in matters pertaining to the Internet Standards.

         3. Methods for assuring that for any particular Internet
            Standard, procedures have been followed satisfactorily by all
            parties so that everyone with an interest has had a fair
            opportunity to be heard.


       The Working Group will begin with a review of the procedures for making
       IAB appointments as documented in RFC 1358 and a review of
       the standards-making process documented in RFC 1310.

       The Working Group has a goal of issuing a final report in time for IESG
       consideration and publication as an RFC before the ISOC Board Trustee's
       meeting in December 1992.  Given the compressed timescale, the Working
       Group will conduct most of its deliberations by electronic mail on the
       POISED Working Group mailing list.   There will also be a preliminary
       report and discussions at the November 1992 IETF meeting in Washington,
       DC.

       This will be a normal IETF Working Group, i.e., the mailing list and all
       discussions will be completely open.

Internet Drafts:

  No Current Internet drafts.

Point-to-Point Protocol Extensions (pppext)

Charter

Chair(s):
     Brian Lloyd  <[e-mail]>

Internet Area Director(s)
     Stev Knowles  <[e-mail]>
     David Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Point-to-Point Protocol (PPP) was designed to encapsulate multiple
protocols.  IP was the only network layer protocol defined in the
original documents.  The Working Group is defining the use of other
network level protocols and options for PPP. The Group will define the
use of protocols including: bridging, ISO, DECNET (Phase IV and V),
XNS, and others.  In addition it will define new PPP options for the
existing protocol definitions, such as stronger authentication and
encryption methods.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 88 Mar 93  <draft-ietf-ppp-requirements-02.txt>
                Requirements for an Internet Standard Point-to-Point Protocol

 Jun 92 Oct 92  <draft-ietf-pppext-ipxcp-02.txt>
                The PPP Internetwork Packet Exchange Control Protocol  (IPXCP)

 Jun 92 Jul 92  <draft-ietf-pppext-bridgemib-01.txt>
                The Definitions of Managed Objects for the Bridge Network
                Control Protocol of the Point-to-Point Protocol

 Jun 92 Jul 92  <draft-ietf-pppext-ipcpmib-01.txt>
                The Definitions of Managed Objects for the IP Network Control
                Protocol of the Point-to-Point Protocol

 Jun 92 Jul 92  <draft-ietf-pppext-lcpmib-01.txt>
                The Definitions of Managed Objects for the Link Control
                Protocol of the Point-to-Point Protocol

 Jun 92 Jul 92  <draft-ietf-pppext-secmib-01.txt>
                The Definitions of Managed Objects for the Security Protocols
                of the Point-to-Point Protocol

 Dec 92 Apr 93  <draft-ietf-pppext-cipx-02.txt>
                Compressing IPX Headers Over WAN Media (CIPX)

 Jan 93 Mar 93  <draft-ietf-pppext-lcpext-01.txt>
                PPP LCP Extensions

 Mar 93 New     <draft-ietf-pppext-isdn-00.txt>
                PPP over ISDN

 Mar 93 New     <draft-ietf-pppext-x25-00.txt>
                PPP over X.25

 Mar 93 New     <draft-ietf-pppext-fr-00.txt>
                PPP over Frame Relay

 Mar 93 New     <draft-ietf-pppext-sonet-00.txt>
                PPP over SONET

Router Requirements (rreq)

Charter

Chair(s):
     Philip Almquist  <[e-mail]>

Internet Area Director(s)
     Stev Knowles  <[e-mail]>
     David Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Router Requirements Working Group has the goal of rewriting
the existing Router Requirements RFC, RFC-1009, and a) bringing
it up to the organizational and requirement explicitness levels
of the Host Requirements RFC's, as well as b) including
references to more recent work, such as OSPF and BGP.

The Working Group will also instigate, review, or (if appropriate)
produce additional RFCs on related topics.  To date, Group members have
produced draft documents discussing the operation of routers which are in
multiple routing domains (3 papers), TOS, and a routing table MIB.

The purposes of this project include:

- Defining what an IP router does in sufficient detail that
  routers from different vendors are truly interoperable.

- Providing guidance to vendors, implementors, and purchasers of
  IP routers.

The Working Group has decided that, unlike RFC-1009, the Router Requirements
document should not discuss Link Layer protocols or address resolution.
Instead, those topics should be covered in a separate Link Layer Requirements
document, applicable to hosts as well as routers.  Whether this Group will
create the Link Layer Requirements is still to be determined.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Sep 90 Mar 93  <draft-ietf-rreq-iprouters-04.txt>
                Requirements for IP Routers Volume 1: Introduction

Source Demand Routing (sdr)

Charter

Chair(s):
     Deborah Estrin  <[e-mail]>
     Tony Li  <[e-mail]>

Routing Area Director(s)
     Robert Hinden  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           jerico.usc.edu:~/pub/sdrp

Description of Working Group:

The SDR Working Group is chartered to specify and promote the use of
SDR (Source Demand Routing Protocol) as an interdomain routing protocol
capability in conjunction with IDRP and BGP interdomain routing
protocols.  The purpose of SDR is to support source-initiated selection
of interdomain routes, to complement the intermediate node selection
provided by BGP/IDRP.

The goal of the SDR working group is to release the components of SDR
as IETF Prototypes and to obtain operational experience with SDR in the
Internet.  Once there is enough experience with SDR the working group
will submit the SDR components to the IESG for standardization.

SDR has four components: Packet formats for protocol control messages
and encapsulation of user datagrams, Processing and forwarding of user
data and control messages, Routing information distribution/collection
and route computation, Configuration and usage.


Our strategy is to:

1. Define the format, processing and forwarding of user datagram and
control messages so that SDR can be used very early on as an efficient
means of supporting "configured" inter-domain routes.  User packets are
encapsulated along with the source route and forwarded along the
"configured" route.  Routes are static at the inter-domain level, but
are not static in terms of the intra-domain paths that packets will
take between specified points in the SDR route. The impact of
encapsulation on MTU, ICMP, performance, etc., are among the issues
that must be evaluated before deployment.

2. Develop simple schemes for a) collecting dynamic domain-level
connectivity information, and b) route construction based on this
information, so that those domains that want to can make use of a
richer, and dynamic set of SDR routes.

3. In parallel with 1 and 2, develop usage and configuration documents
and prototypes that demonstrate the utility of static-SDR and
simple-dynamic-SDR.

4. After gaining some experience with the simple schemes for
distribution, develop a second generation of information distribution
and route construction schemes.  We hope to benefit from discussions
with IDPR and NIMROD developers at this future stage because the issues
faced are similar.

5. We will also investigate the addition of security options into the
SDRP forwarding and packet format specifications.

Internet Drafts:

  No Current Internet drafts.

Simple Internet Protocol (sip)

Charter

Chair(s):
     Christian Huitema  <[e-mail]>
     Steve Deering  <[e-mail]>

Internet Area Director(s)
     Stev Knowles  <[e-mail]>
     David Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

   SIP is another candidate for IPv7. The purpose of the Working Group
   is to finalize the SIP family of protocol, and to foster the early
   development and experimentation of this protocol.

   There are two major characteristics of the SIP proposal: it is very
   much a continuation of IP, and it aims at maximum simplicity. A
   short hand definition of SIP could be ``64 bits IP with useless
   overhead removed''.

   Following the IP model, SIP uses globally-unique addresses,
   hierarchically structured for efficient routing. SIP addresses are
   64 bits long, which we believe adequate to scale the Internet up
   to,  say, thousands of internet-addressable devices in every office,
   every residence, and every vehicle in the world.

   The quest of simplicity in SIP has been described as parallel to the
   RISC philosophy. The minimal SIP header contains only those fields
   which are necessary to achieve our goal: routing packets efficently
   in a very large internet. As a result of this design philosophy, the
   SIP header is much simpler than the IP header. Simplicity
   facilitates high-performance implementation and increases the
   likelihood of correct implementation.

   Contrary to several other IPv7 candidates, the SIP effort is
   focused mostly on the description of the final state, not on the
   description of the transition. This is due to a coordination with
   the IPAE working group, which has already engaged an intensive study
   of transition problems, with SIP in mind as a final state.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 92 New     <draft-deering-sip-00.txt>
                Simple Internet Protocol (SIP) Specification

 Mar 93 New     <draft-ietf-sip-rip-00.txt>
                SIP-RIP

 Apr 93 New     <draft-ietf-sip-bsd-api-00.txt>
                SIP Program Interfaces for BSD Systems

SNMP Security (snmpsec)

Charter

Chair(s):
     James Galvin  <[e-mail]>
     Keith McCloghrie  <[e-mail]>

Security Area Director(s)
     Stephen Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           [e-mail]

Description of Working Group:

Enhancements to the SNMP network management framework are being
contemplated within the SNMP Version 2 Working Group of the IETF. The
SNMP Security Working Group is chartered to consider changes to RFCs
1351, 1352, 1353 that may be required either for consistency with this
SNMP evolution effort or to reflect implementation experience with the
current specifications.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Dec 92 Mar 93  <draft-ietf-snmpsec-partyv2-03.txt>
                Party MIB for version 2 of the Simple Network Management
                Protocol (SNMPv2)

 Dec 92 Mar 93  <draft-ietf-snmpsec-adminv2-03.txt>
                Administrative Model for version 2 of the Simple Network
                Management Protocol (SNMPv2)

 Dec 92 Mar 93  <draft-ietf-snmpsec-secv2-03.txt>
                Security Protocols for version 2 of the Simple Network
                Management Protocol (SNMPv2)

SNMP Version 2 (snmpv2)

Charter

Chair(s):
     Bob Stewart  <[e-mail]>

Network Management Area Director(s)
     Marshall Rose  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           thumper.bellcore.com:~/pub/davin/snmp2-archive

Description of Working Group:

This Working Group is chartered to consider technical contributions to
the SNMP evolution process and to produce a single recommendation as
to which contributions (or combinations or modifications thereof)
should define the next generation SNMP network management framework.

The announced deadline for technical contributions to the SNMP
evolution process is September 10, 1992. Any individual interested in
contributing to this process should prepare and submit his/her
contribution according to the requirements for detail, completeness,
copyright, and format set forth in the original announcement. This
Working Group is under no obligation to consider contributions that do
not meet these basic requirements or contributions that are not
submitted by the contribution deadline.

This Working Group has the option of (a) rejecting any or all
contributions as the basis for positive evolution, (b) accepting any
or all contributions as candidates for standardization, or (c)
modifying or combining any or all contributions to produce consensus
proposals for standardization.

The product of the Working Group will be a single recommendation to
the IESG identifying those submitted specifications (or modifications
thereof), if any, whose standardization as part of the SNMP framework
is agreed to be warranted and desirable.  The Working Group will not
be chartered to produce tutorial, explanatory, advisory, or
informational documents of any kind.

In its deliberations, the Working Group will take special cognizance
of architectural principles on which the historic success of SNMP has
rested:

(1) The SNMP framework minimizes the overall cost of a manageable
network by minimizing the cost and complexity of those management
system components that are most numerous.

(2) The SNMP framework fosters ubiquity of deployment by admitting the
widest possible range of implementation strategies.

(3) The SNMP framework fosters operational robustness by realizing
management system function as closely as possible to centers of
responsible authority.

(4) The SNMP framework fosters operational robustness by locating
control of resources consumed by the management activity (e.g.,
bandwidth, processing) as closely as possible to centers of
responsible authority.

Moreover, the deliberations of the Working Group will take special
cognizance of at least two aspects of evolutionary logistics:

(1) A single transition from existing SNMP technology to the next
stage of SNMP evolution is highly desirable; multi-stage or protracted
transitions are less desirable.

(2) Minimizing the number of distinct management technologies
concurrently deployed in the Internet is highly desirable.

Consistent with the community desire for timely, deliberate progress,
the Working Group may be disbanded at the time of the IETF plenary
meeting in the Spring of 1993 regardless of whether or not it has
produced the single recommendation required by its Charter.

This Working Group is not chartered to consider security aspects of
the SNMP framework, as these are addressed as a matter of course by an
existing IETF working group.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 92 Mar 93  <draft-ietf-snmpv2-tm-07.txt>
                Transport Mappings for version 2 of the Simple Network
                Management Protocol (SNMPv2)

 Jul 92 Mar 93  <draft-ietf-snmpv2-coex-06.txt>
                Coexistence between version 1 and version 2 of the Network
                Management Framework

 Jul 92 Mar 93  <draft-ietf-snmpv2-tc-06.txt>
                Textual Conventions for version 2 of the Simple Network
                Management Protocol (SNMPv2)

 Jul 92 Mar 93  <draft-ietf-snmpv2-smi-06.txt>
                Structure of Management Information for version 2 of the Simple
                Network Management Protocol (SNMPv2)

 Jul 92 Mar 93  <draft-ietf-snmpv2-intro-06.txt>
                Introduction to version 2 of the Internet-standard Network
                Management Framework

 Jul 92 Mar 93  <draft-ietf-snmpv2-proto-06.txt>
                Protocol Operations for version 2 of the Simple Network
                Management Protocol (SNMPv2)

 Jul 92 Mar 93  <draft-ietf-snmpv2-m2m-06.txt>
                Manager to Manager Management Information Base

 Jul 92 Mar 93  <draft-ietf-snmpv2-mib-06.txt>
                Management Information Base for version 2 of the Simple Network
                Management Protocol (SNMPv2)

 Nov 92 Mar 93  <draft-ietf-snmpv2-conf-03.txt>
                Conformance Statements for version 2 of the Simple Network
                Management Protocol (SNMPv2)

Service Location Protocol (svrloc)

Charter

Chair(s):
     John Veizades  <[e-mail]>
     Scott Kaplan  <[e-mail]>

Service Applications Area Director(s)
     Dave Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           apple.com:~/pub/srv-location/svr-loc-archive

Description of Working Group:

The Service Location Working Group is chartered to investigate
protocols to find and bind to service entities in a distributed internetworked
environment.  Issues that must be addressed are how such a protocol would
interoperate with existing directory based services location protocols.
Protocols that would be designed by this Group would be viewed as an adjunct
to directory service protocols.  These protocols would be able to provide a
bridge between directory services and current schemes for service location.

The nature of the services location problem is investigative in
principle.  There is no mandate that a protocol should be drafted as part
of this process.  It is the mandate of this Group to understand the operation
of services location and then determine the correct action in their view
whether it be to use current protocols to suggest a services location
architecture or to design a new protocol to compliment current architectures.



Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 93 New     <draft-ietf-svrloc-resloc-00.txt, .ps>
                Resource Location Protocol

TCP Large Windows (tcplw)

Charter

Chair(s):
     David Borman  <[e-mail]>

Transport Area Director(s)
     Allison Mankin  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The TCP Large Windows Working Group is chartered to produce a
specification for the use of TCP on high delay, high bandwidth paths.
To this end, this Working Group recommended RFC 1072 ``TCP extensions
for long-delay paths'' and RFC 1185 ``TCP Extension for High-Speed
Paths'' be published jointly as a Proposed Standard.  Deficiencies in
the technical details of the documents were identified by the
End-to-End Research Group of the IRTF.  Rather than progress the
standard with known deficiencies, the IESG tasked the End-to-End
Research Group to fix and merge these two documents into a single
protocol specification document. This review was done on the
[e-mail] mailing list.

The TCP Large Windows Working Group is being resurrected for a one
time meeting, to review and if appropriate, approve this new document.


Internet Drafts:

  No Current Internet drafts.

TELNET (telnet)

Charter

Chair(s):
     Steve Alexander  <[e-mail]>

Applications Area Director(s)
     Brewster Kahle  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The TELNET Working Group will examine RFC 854, ``Telnet Protocol
Specification'', in light of the last six years of technical
advancements, and will determine if it is still accurate with how the
TELNET protocol is being used today.  This Group will also look at all
the TELNET options, and decide which are still germane to current day
implementations of the TELNET protocol.


(1) Re-issue RFC 854 to reflect current knowledge and usage of the
    TELNET protocol.

(2) Create RFCs for new TELNET options to clarify or fill in any
    missing voids in the current option set.  Specifically:

    - Environment variable passing
    - Authentication
    - Encryption
    - Compression

(3) Act as a clearing-house for all proposed RFCs that deal with the
    TELNET protocol.



Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Apr 90 Apr 93  <draft-ietf-telnet-encryption-02.txt>
                Telnet Authentication and Encryption Option

 Apr 93 Apr 93  <draft-ietf-telnet-envmnt-option-01.txt>
                Telnet Environment Option

 Apr 93 New     <draft-ietf-telnet-interoperability-00.txt>
                Telnet Environment Option Interoperability Issues

Minimal OSI Upper-Layers (thinosi)

Charter

Chair(s):
     Peter Furniss  <[e-mail]>

Applications Area Director(s)
     Brewster Kahle  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           pluto.ulcc.ac.uk:/ulcc/thinosi/thinosi-mail-archive.txt

Description of Working Group:

The OSI upper-layer protocols (above Transport) are rich in function
and specified in large, complex and numerous documents. However, in
supporting a particular application, the protocol actually used is only
a subset of the whole. An implementation is not required to support
features it never uses, and it is or should be possible to have
relatively lightweight implementations specialized for a particular
application or group of applications with similar requirements. The
application protocol could be an OSI application-layer standards or a
protocol originally defined for TCP/IP or other environment. It will be
easier to produce such implementations if the necessary protocol is
described concisely in a single document.

An implementation based on this principle, of the mapping of X Window
System protocol over OSI upper-layers exists.

The Working Group is chartered to produce two documents

``Skinny bits for byte-stream'' a specification of the bit (octet)
sequences that implement the OSI upper-layer protocols (Session,
Presentation and ACSE) as needed to support an application that
requires simple connection, and byte-stream read and write. This will
be based on the octet sequences needed to support X. This will not be
expected to be provide a full equivalent of TCP, nor to cover specific
standardized protocols.

``Skinny bits for Directory'' a specification of the bit sequences
needed for the Directory Access Protocol - in the same style as a), but
to include DAP. The level of functionality of this is to be
determined.

An important aspect of the Group's work is find out if it is possible
to produce useful and concise specification of this kind. A  minor part
is to think of better names.

The Group will also encourage the deployment of X/osi implementations
and interworking experiments with it.


Internet Drafts:

  No Current Internet drafts.

Trusted Network File Systems (tnfs)

Charter

Chair(s):
     Fred Glover  <[e-mail]>

Service Applications Area Director(s)
     Dave Crocker  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           [e-mail]

Description of Working Group:

The Trusted Network File  System Working Group is chartered to define
protocol extensions to the Network File System (NFS) Version 2 protocol
which support network file access in a Multilevel Secure (MLS) Internet
environment.  MLS functionality includes Mandatory Access Control (MAC),
Discretionary Access Control (DAC), authentication, auditing, documentation,
and other items as identified in the Trusted Computer System Evaluation
Criteria (TCSEC) and Compartmented Mode Workstation (CMW) documents.

The primary objective of this Working Group is to specify extensions to the
NFS V2 protocol which support network file access between MLS systems.  It
is intended that these extensions should introduce only a minimal impact on
the existing NFS V2 environment, and that unmodified NFS V2 clients and
servers will continue to be fully supported.

Transferring information between MLS systems requires exchanging additional
security information along with the file data.  The general approach to be
used in extending the NFS V2 protocol is to transport additional user context
in the form of an extended NFS UNIX style credential between a Trusted NFS
(TNFS) client and server, and to map that context into the appropriate server
security policies which address file access.  In addition, file security
attributes are to be returned with each TNFS procedure call.  Otherwise,
the NFS V2 protocol remains essentially unchanged.

The Trusted System Interoperability Group (TSIG) has already developed a
specification which defines a set of MLS extensions for NFS V2, and has also
planned for the future integration of Kerberos as the authentication mechanism.
The TNFS Working Group should be able to use the TSIG Trusted NFS document
as a foundation, and to complete the IETF TNFS specification within the
next 3-6 months.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 91 Mar 93  <draft-ietf-tnfs-spec-03.txt>
                A Specification of Trusted NFS (TNFS) Protocol Extensions


Token Ring Remote Monitoring (trmon)

Charter

Chair(s):
     Michael Erlinger  <[e-mail]>

Network Management Area Director(s)
     Marshall Rose  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Token Ring Remote Monitoring MIB Working Group is chartered to
produce a new MIB specification that extends the facilities of the
existing Remote Monitoring (RMON) MIB (RFC 1271) for use in monitoring
IEEE 802.5 Token Ring networks.

The Token Ring RMON MIB extensions will be developed in the same
architectural framework as the existing Ethernet-based RMON MIB.  The
original RMON MIB architecture was designed with the intention of
incorporating MIB extensions devoted to monitoring other network media
types.  This Token Ring activity is the first attempt at such
integration.

In creating the Token Ring Extensions the Working Group will, wherever
possible, conform to terminology and concepts defined by relevant IEEE
standards.  It may be that a MIB devoted to monitoring may need to
expand on the IEEE objects and definitions.  Such modifications will
be accompanied by a detailed rationale.

All work produced by the Token Ring Remote Monitoring Working Group
will be consistent with the existing SNMP network management framework
and standards.


Internet Drafts:

  No Current Internet drafts.

TCP/UDP over CLNP-addressed Networks (tuba)

Charter

Chair(s):
     Mark Knopper  <[e-mail]>
     Peter Ford  <[e-mail]>

Internet Area Director(s)
     Stev Knowles  <[e-mail]>
     David Piscitello  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The TUBA Working Group will work on extending the Internet Protocol
suite and architecture by increasing the number of end systems which
can be effectively addressed and routed.  The TUBA effort will expand
the ability to route Internet packets by using addresses which support
more hierarchy than the current Internet Protocol (IP) address space.
TUBA specifies the continued use of Internet Transport Protocols, in
particular TCP and UDP, but encapsulated in ISO 8473 (CLNP) packets.
This will allow the continued use of Internet application protocols
such as FTP, SMTP, Telnet, etc. An enhancement to the current system
is mandatory due to the limitations of the current 32 bit IP
addresses.  TUBA seeks to upgrade the current system by a transition
from the use of the Internet Protocol version 4 to ISO/IEC 8473 (CLNP)
and the corresponding large Network Service Access Point address
space.


In addition to protocol layering issues and ``proof of concept'' work,
the TUBA approach will place significant emphasis on the engineering
and operational requirements of a large, global, multilateral public
data network.  TUBA will work to maximize interoperatability with the
routing and addressing architecture of the global CLNP infrastructure.
The TUBA Working Group will work closely with the IETF NOOP and
IPRP-for-IP Working Groups to coordinate a viable CLNP based Internet
which supports the applications which Internet users depend on such as
Telnet, FTP, SMTP, NFS, X, etc.  The TUBA Working Group will also work
collaboratively with communities which are also using the CLNP
protocol, and will consider issues such as interoperability,
applications coexisting on top of multiple transports, and the
evolution of global public connectionless datagram networks, network
management and instrumentation using CLNP and TUBA, and impact on
routing architecture and protocols given the TUBA transition.

The TUBA Working Group will consider how the TUBA scheme will support
transition from the current IP address space to the future NSAP
address space without discontinuity of service, although different
manufacturers, service providers, and sites will make the transition
at different times. In particular, the way in which implementations
relying on current 32 bit IP addresses will migrate must be
considered.  TUBA will ensure that IP addresses can be assigned, for
as long as they are used, independently of geographical and routing
considerations. One option is to embed IP addresses in NSAP addresses,
possibly as the NSAP end-system identifier. Whatever scheme is chosen
must run in a majority of *-GOSIPs and other NSAP spaces. The TUBA
strategy will require a new mapping in the DNS from NAMEs to NSAP
addresses.

The rationale RFC (RFC-1347) documents issues of transition and
coexistence, among unmodified ``IP'' hosts and hosts which support
``TUBA'' hosts.  Hosts wishing full Internet connectivity will need to
support TUBA.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Sep 92 Jan 93  <draft-ietf-tuba-clnp-02.txt>
                Use of ISO CLNP in TUBA Environments

 Nov 92 New     <draft-ietf-tuba-address-00.txt, .ps>
                Addressing and End Point Identification, For Use with TUBA

User Connectivity (ucp)

Charter

Chair(s):
     Dan Long  <[e-mail]>

Operational Requirements Area Director(s)
     Scott Bradner  <[e-mail]>
     Bernhard Stockman  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The User Connectivity Working Group will study the problem of how to
solve network users' end-to-end connectivity problems.

Internet Drafts:

  No Current Internet drafts.

Uninterruptible Power Supply (upsmib)

Charter

Chair(s):
     Jeff Case  <[e-mail]>

Network Management Area Director(s)
     Marshall Rose  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ucs.utk.edu:~/pub/ups-mib/mail-archive

Description of Working Group:

This Working Group will produce a document that defines MIB objects
for use in monitoring and (possibly) control of both high-end and
low-end UPSs and related systems (e.g., power distribution systems or
power conditioning systems). Related devices may be addressed in
this effort to the extent that the primary focus on UPSs is not
compromised.

The MIB object definitions produced will be for use by SNMP and will
be consistent with existing SNMP standards and framework.

At its discretion, the Working Group may fulfill its Charter by the
development of distinct MIB definitions for UPS systems of differing
capabilities, but the number of MIB definitions produced by the
Working Group will not exceed two.

At its discretion, the Working Group may produce an additional
document defining traps that support the management of UPSs.

Although the Working Group may choose to solicit input or expertise
from other relevant standards bodies, no extant standards efforts or
authorities are known with which alignment of this work is required.

Because the structure of UPS implementations varies widely, the
working group shall take special care that its definitions reflect a
generic and consistent architectural model of UPS management rather
than the structure of particular UPS implementations.


Internet Drafts:

  No Current Internet drafts.

Uniform Resource Identifiers (uri)

Charter

Chair(s):
     Jim Fullton  <[e-mail]>
     Alan Emtage  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           archives.cc.mcgill.ca:~/pub/uri-archive

Description of Working Group:

The Uniform Resource Identifiers Archives Working Group is chartered to
define a set of standards for the encoding of system independent
Resource Location and Identification information for the use of
Internet information services.

This Working Group is expected to produce a set of documents that will
specify standardized representations of Uniform Resource Locators
(URLs) which specify a standardized method for encoding location and
access information across multiple information systems. Such standards
are expected to build upon the document discussed at the UDI BOF
session held during the 24th IETF meeting in Boston, Unique Resource
Serial Numbers (URSNs) which specify a standardized method for encoding
unique resource identification information for Internet resources and
Uniform Resource Identifiers (URIs), which specify a standardized
method for encoding combined resource identification and location
information systems to be used for resource discovery and access
systems in an Internet environment.

Such a set of standards will provide a framework that: allows the
Internet user to specify the location and access information for files
and other resources on the Internet, allows users and network-based
tools to uniquely identify specific resources on the Internet, and
allows the creation and operation of resource discovery and access
systems for the Internet.  The security of such resource discovery
services will also be considered to be an integral part of the work
of this Group.


Internet Drafts:

  No Current Internet drafts.


User Services (uswg)

Charter

Chair(s):
     Joyce K. Reynolds  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           nnsc.nsf.net:~/nsfnet/us-wg*

Description of Working Group:

The User Services Working Group provides a regular forum for people
interested in user services to identify and initiate projects designed
to improve the quality of information available to end-users of the
Internet.  (Note that the actual projects themselves will be handled
by separate groups, such as IETF working groups created to perform certain
projects, or outside organizations such as SIGUCCS.

(1) Meet on a regular basis to consider projects designed to improve services
    to end-users.  In general, projects should:

       - Clearly address user assistance needs;
       - Produce an end-result (e.g., a document, a program plan, etc.);
       - Have a reasonably clear approach to achieving the end-result
         (with an estimated time for completion);
       - Not duplicate existing or previous efforts.

(2) Create working groups or other focus groups to carry out projects deemed
    worthy of pursuing.

(3) Provide a forum in which user services providers can discuss and identify
    common concerns.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Apr 93 New     <draft-ietf-uswg-fyi-00.txt>
                FYI on "What is the Internet?"

Whois and Network Information Lookup Service (wnils)

Charter

Chair(s):
     Joan Gargano  <[e-mail]>

User Services Area Director(s)
     Joyce Reynolds  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ucdavis.edu:~/pub/ietf-wnils-archive

Description of Working Group:

The Network Information Center (NIC) maintains the central NICNAME
database and server, defined in RFC 954, providing online look-up of
individuals, network organizations, key nodes, and other information
of interest to those who use the Internet.  Other distributed
directory information servers and information retrieval tools have
been developed and it is anticipated more will be created.  Many sites
now maintain local directory servers with information about
individuals, departments and services at that specific site.
Typically these directory servers are network accessible.  Because
these servers are local, there are now wide variations in the type of
data stored, access methods, search schemes, and user interfaces.  The
purpose of the Whois and Network Information Lookup Service (WNILS)
Working Group is to expand and define the standard for WHOIS services,
to resolve issues associated with the variations in access and to
promote a consistent and predictable service across the network.

Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 92 Apr 93  <draft-ietf-wnils-whois-01.txt>
                Architecture of the Whois++ Index Service

X.25 Management Information Base (x25mib)

Charter

Chair(s):
     Dean Throop  <[e-mail]>

Network Management Area Director(s)
     Marshall Rose  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           dg-rtp.dg.com:~/x25mib/Current.Mail

Description of Working Group:

This Working Group will produce a set of three documents that describe
the Management Information Base for X.25.  The first document will
specify the objects for the X.25 Link Layer. The second document will
specify the objects for the X.25 Packet Layer.  The third document will
specify the objects for managing IP over X.25.  The Working Group need
not consider the Physical Layer because the ``Definition of Managed
Objects for RS-232-like Hardware Devices'' already defines sufficient
objects for the Physical Layer of a traditional X.25 stack.  Any
changes needed at the Physical Layer will be addressed as part of that
activity.

The X.25 object definitions will be based on ISO documents 7776 and
8208 however nothing should preclude their use on other similar or
interoperable protocols (i.e., implementations based on CCITT
specifications).

The objects in the Link and Packet Layer documents, along with the
RS-232-like document, should work together to define the objects
necessary to manage a traditional X.25 stack.  These objects will be
independent of any client using the X.25 service.  Both of these
documents assume the interface table as defined in MIB-II contains
entries for the Link and Packet Layer interfaces.  Thus these documents
will define tables of media specific objects which will have a one to
one mapping with interfaces of ifType ddn-x25, rfc877-x25, or lapb.
The objects for the IP to X.25 convergence functions will be defined
analogously with the ipNetToMedia objects in MIB II.

The Working Group will endeavor to make each layer independent from
other layers.  The Link Layer will be independent of any Packet Layer
protocol above it and should be capable of managing an ISO 7776 (or
similar) Link Layer provider serving any client.  Likewise the X.25
Packet Layer objects should be independent of the Link Layer below it
and should be capable of managing an ISO 8208 (or similar) Packet Layer
serving any client.

The Working Group will also produce a third document specifying the
objects for managing IP traffic over X.25.  These objects will reside
in their own table but will be associated with the X.25 interfaces used
by IP.  These objects will not address policy decisions or other
implementation specific operations associated with X.25 connection
management decisions except as explicitly described in existing
standards.  These objects will manage the packet flow between IP and
the X.25 Packet Layer specifically including observation of packet
routing and diagnosis of error conditions.  Progress on the Link and
Packet Layer documents will not depend on progress of the IP over X.25
document.  The IP over X.25 document will proceed on a time available basis after work on the Link and Packet Layer documents and as such the Link and Packet Layers may be completed before the IP over X.25 work.

All documents produced will be for use by SNMP and will be consistent
with other SNMP objects, conventions, and definitions (such as Concise
MIB format).  To the extent feasible, the object definitions will be
consistent with other network management definitions.  In particular
ISO/IEC CD 10733 will be considered when defining the objects for the
X.25 Packet Layer.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 91 Jan 93  <draft-ietf-x25mib-ipox25mib-04.txt>
                SNMP MIB extension for MultiProtocol Interconnect over X.25

X.400 Operations (x400ops)

Charter

Chair(s):
     Alf Hansen  <[e-mail]>
     Tony Genovese  <[e-mail]>

Applications Area Director(s)
     Brewster Kahle  <[e-mail]>
     Erik Huizer  <[e-mail]>

Mailing lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

X.400 management domains are being deployed today on the Internet. There is a
need for coordination of the various efforts to insure that they can
interoperate and collectively provide an Internet-wide X.400 message transfer
service connected to the existing Internet mail service. The overall goal of
this Group is to insure interoperability between Internet X.400 management
domains and the existing Internet mail service. The specific task of this
Group is to produce a document that specifies the requirements and conventions
of operational Internet PRMDs.


Internet Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 92 Mar 93  <draft-ietf-x400ops-mhs-service-05.txt>
                Routing coordination for X.400 MHS services within a multi
                protocol / multi network environment Table Format V3 for static
                routing

 Mar 92 Mar 93  <draft-ietf-x400ops-mgtdomains-ops-05.txt>
                Operational Requirements for X.400 Management Domains in the
                GO-MHS Community

 Jun 92 Mar 93  <draft-ietf-x400ops-charactersets-02.txt>
                X.400 use of extended character sets

 Nov 92 Mar 93  <draft-ietf-x400ops-postmaster-01.txt>
                Postmaster Convention for X.400 Operations

 Dec 92 Jan 93  <draft-ietf-x400ops-admd-01.txt>
                Assertion  of C=US; A=IMX

 Jan 93 Jan 93  <draft-ietf-x400ops-dnsx400maps-02.txt>
                Using the Internet DNS to maintain RFC1327 Address Mapping
                Tables

 Feb 93 Mar 93  <draft-ietf-x400ops-dnsx400rout-02.txt>
                Using the Internet DNS to maintain X.400 MHS Routing
                Informations

 Feb 93 New     <draft-ietf-x400ops-evaluation-admd-00.txt>
                Evaluation of ADMDs and Integration aspects with respect to the
                R&D messaging community

 Mar 93 New     <draft-ietf-x400ops-tbl-dist-00.txt>
                Table distribution